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Practical  Tools  for  Electronic  Records 
Management  and  Preservation 


This  briefing  paper  summarizes  the  results  of  a  > 

cooperative  project  sponsored  in  part,  by  a  research 
grant  from  the  National  Historical  Publications  and 

'  Records  Commission.  ^ 

. . . .  . . - 

„  .  .  ....  '  '  ' 

The  project,  called  “Models  for  Action:  Practical 

i  :  Approaches  to  Electronic  Records  Management  and 
Preservation,”  focused  on  the  development  of  fl- 
practical  tools  to  support  the  integration  of  essential 
.electronic  records  management  requirements  into  |he 
^  design  of  new  informatibn  systems. 

The  project  was  conducted  from  1996  to  1998 
throu^  a  partnership  between  the  New  York  State 
Archives  and  Record  Administration  and  the  Center 
for  Technology  in  Government 

The  project  team  also  included  staff  from  the  NYS 
Adirondack  Park  Agency,  eight  corporate  parmers 
led  by  Intergraph  Corporation,  and  University  at 
Albany  faculty  and  graduate  students. 


Organizations  need  to  create  and  maintain  records  to  carry 
out  their  business  activities  and  to  document  actions  and 
decisions.  Organizations  are  increasingly  relying  upon 
electronic  information  to  manage  work  and  make 
decisions.  Many  transactions  that  were  once  paper-based 
are  now  being  performed  electronically,  as  networked 
computer  systems  that  once  played  a  purely  supportive 
role  have  moved  to  center  stage.  However,  with  the 
shift  from  paper  to  digital  information,  many  organizations 
find  that  their  current  electronic  records  are  not  sufficient 
to  support  the  evidentiary  needs  of  their  business 
functions.  Others  face  the  problem  of  linking  documents 
created  in  different  forms  and  formats  to  business 
transactions.  Many  organizations  are  in  danger  of  losing 
access  to  records  stored  in  personal  computers,  e-mail 
boxes,  or  personal  local  area  network  directories.  From 
an  archival  perspective,  focused  on  the  long-term  societal 
and  organizational  need  for  records,  these  problems  result 
in  partial  or  complete  loss  of  records  of  enduring  value. 

In  recent  years,  significant  theoretical  work  has  been 
done  in  the  area  of  electronic  records  management; 
however,  little  of  this  work  has  been  translated  into 
practical,  implementable  solutions.  This  briefing  paper 
bridges  the  gap  between  theory  and  practice  by  presenting 
generalizable  tools  that  link  records  management  practices 
to  business  objectives.  This  connection  can  be  understood 
most  readily  at  the  business  process  level  where  workflow, 
information  flow,  and  service  delivery  come  together. 


This  material  is  based  upon  work  supported  in  part  by  the  National  Historical  Publications  and  Records  Commission 

under  Grant  No.  96023. 

©  1999  Center  for  Technology  in  Government 
The  Center  grants  permission  to  reprint  this  document  provided  it  is  printed  in  its  entirety. 


Electronic  Records  Management  Goals 


This  paper  presents  an  easy  to  understand  foundation 
for  electronic  records  management  considerations.  It 
also  presents  practical  tools  that  seamlessly  integrate  into 
the  system  design  process  and  result  in  the  identification 
of  technical  specifications  and  opportunities  for  improving 
performance  through  improved  access  to  records.  The 
tools  also  identify  critical  management  and  policy  factors 
that  must  be  in  place  to  support  a  full  system 
implementation.  These  tools  can  be  used  by  any 
organization  to: 

1.  Bring  the  record  to  the  forefront  of  system 
design  activities.  The  tools  shift  the  focus  fi'om 
technology  to  business  processes  and  the  records 
associated  with  these  activities.  They  establish  the 
concept  of  a  ‘record’  as  the  centerpiece  of  system 
design  efforts  and  bring  the  maintenance  and  ongoing 
accessibility  of  records  to  the  forefront  of  the  system 
design  and  development  process. 

2 .  Identify  electronic  records  functionality  as  part 
of  system  design.  The  business  requirements  that 
underlie  the  records  management  requirements  drive 
the  selection  of  appropriate  supporting  technologies. 
The  tools  pose  questions  associated  with  ongoing 
internal  and  external  secondary  access  to  records, 
support  the  selection  of  appropriate  technologies, 
and  identify  important  system  migration  issues. 

3.  Create  electronic  records  that  support  legal 
and  evidentiary  needs.  The  tools  support  the 
identification  of  all  authenticity  requirements  tied  to 
a  business  process  including  legal  admissibility.  They 
reveal  how  authenticity  and  evidentiary  needs  cannot 
be  addressed  by  technology  alone  and  must  be 
supported  by  appropriate  management  practices  and 
organizational  policies. 


4.  Create  electronic  records  that  are  accessible 
and  usable  over  time.  The  business  process  focus 
of  the  tools  identifies  the  specific  record  components 
that  must  be  captured  at  each  step  during  the  course 
of  a  transaction.  They  address  issues  associated 
with  ongoing  access  to  records  over  time,  and 
identify  technology,  management,  and  policy 
strategies  to  ensure  that  records  are  appropriately 
captured  and  that  they  remain  accessible  for  both 
current  and  future  use. 

5.  Integrate  diverse  document  forms  and  formats 
into  records.  The  tools  help  organizations  identify 
the  diversity  of  forms  and  formats  that  a  system 
must  accommodate  and  facilitate  the  identification 
of  technical  strategies  that  can  be  used  to  ensure 
that  the  required  forms  and  formats  are  integrated 
into  a  record  and  accessible  over  time. 

6 .  Identify  need  for  internal  and  external  primary 
and  secondary  access  to  records.  The  tools  help 
identify  access  needs  from  the  perspective  of 
internal  users  during  a  business  transaction,  as  well 
as  internal  and  external  access  needs  after  a 
transaction  has  been  completed.  The  questions  are 
designed  to  identify  the  components  of  a  record 
required  by  each  of  these  user  types  as  well  as  their 
preferred  or  required  mechanisms  for  accessing 
them.  The  tools,  therefore,  help  ensure  that  the 
value  of  information  collected  and  maintained  during 
a  business  process  will  be  maximized  across  all  user 
groups  and  over  time. 
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Functional  Requirements  to  Ensure  the  Creation, 
Maintenance,  and  Preservation  of  Electronic  Records 


The  Functional  Requirements  to  Ensure  the  Creation, 
Maintenance,  and  Preservation  of  Electronic  Records 
were  developed  to  communicate  to  program  and 
information  technology  managers  what  organizations  must 
achieve  to  ensure  that  electronic  records  are  created, 
maintained,  and  preserved  to  support  their  operational, 
informational,  and  evidentiary  needs.  These  requirements 
should  be  implemented  in  any  system  developed  to  support 
an  organization’s  business  processes.  The  Functional 
Requirements  rest  on  a  concise  definition  of  a  ‘record.’ 
We  define  a  ‘record’  as  the  complete  set  of  documentation 
required  to  provide  evidence  of  a  business  transaction. 

Underpinning  all  three  functional  requirements  is  the 
concept  of  ‘compliance.’  The  laws,  regulations,  and 
policies  that  authorize  or  define  a  specific  government 
business  process,  either  explicitly  or  implicitly,  define  the 
records  management  requirements  for  that  process.  The 


requirements  identify  the  records  that  must  be  created 
and  may  define  requirements  for  records  management, 
access,  content,  and  structure.  Many  professions  or 
disciplines  also  have  established  standards  or  best 
practices  for  records  management  related  to  their  fields. 
An  organization  must  identify  these  requirements  and 
determine  how  they  will  be  implemented.  In  addition, 
changes  in  the  legal  and  regulatory  environment  and  in 
professional  standards  need  to  be  monitored  and  reflected 
in  modifications  to  the  requirements.  Each  requirement 
can  be  mapped  to  a  compliance  factor  based  in  law, 
regulation,  standard,  or  best  practice.  The  use  of  the 
term  ‘best  practice’  refers  to  practices  formally  adopted 
or  generally  accepted  by  a  profession  or  discipline. 
Examples  of  best  practices  include  Generally  Accepted 
Accounting  Principles  and  the  American  Health 
Information  Association’s  Recommended  Practices  for 
Information  and  Documentation. 


A  ‘record’ is  the  complete  set  of  documentation  required  to  provide  evidence  of 

a  business  transaction. 


Three  Functional  Requirements  for  Electronic  Records  Management  &  Preservation 

1 .  Records  Capture  -  Records  are  created  or  captured  and  identified  to  support  the  business 
process  and  meet  all  records  management  requirements  related  to  the  process. 

2.  Records  Maintenance  and  Accessibility  -  Electronic  records  are  maintained  so  that  they  are 
accessible  and  retain  their  integrity  for  as  long  as  they  are  needed. 

3.  System  Reliability  -  A  system  is  administered  in  accordance  with  best  practices  in  the 
information  resource  management  (IRM)  field  to  ensure  the  reliability  of  the  records  it  produces. 
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1.  Records  Capture 

Records  are  created  or  captured  and  identified  to  support 
the  business  process  and  meet  all  recordkeeping 
requirements. 

Justification:  Organizations  must  capture  or  create 
records  necessary  to  carry  out  a  business  process  and  to 
meet  the  specific  recordkeeping  requirements  tied  to  that 
process.  The  capture  and  creation  of  electronic  records 
requires  that  the  system  supporting  the  business  process 
can  capture  or  create  records  in  the  required  form 
including  required  informational  content  and  contextual 
elements  (e.g.,  authorizations,  date  stamps).  Records 
must  also  be  identified  when  they  are  captured  to  ensure 
their  accessibility,  usefulness,  and  preservation. 

A.  Create  or  capture  a  record  for  all  defined 
business  transactions  at  the  appropriate  point  in  the 
business  transaction  or  information  life-cycle. 

B.  Import  records  related  to  business  transactions 
created  in  other  environments. 

C.  Records  comply  with  business  process 
requirements  as  far  as  structure,  content,  and 
context  of  creation. 

1 .  Allow  only  authorized  individuals  to  create  or 
capture  records  at  the  appropriate  point  in  the 
business  transaction  or  information  life-cycle. 

D .  Identified-Unique  identifier  for  each  record. 

1 .  Minimal  record  identification  data  (meta  data)  is 
available  for  all  records. 

a.  Identity  of  record  creator  or  source  or 
owner  (business  unit). 

b.  Date  of  receipt  or  creation. 

c.  Level  of  security  or  restricted  access. 

d.  File  classification. 

e .  Indexing  information  such  as  subj  ect  or 
thesaurus  terms. 

f.  Records  disposition  information  (may  be 
linked  to  file  classification). 


2. Records  Maintenance 

AND  ACCESSIBITY 

Electronic  records  are  maintained  so  that  they  are 
accessible  and  retain  their  integrity  for  as  long  as  they 
are  needed. 

Justification:  Agencies  are  required  to  retain  electronic 
records  to  meet  minimal  legal  retention  requirements 
imposed  by  business  process  specific  administrative 
needs  and  legal  or  regulatoiy  requirements.  Records 
need  to  be  maintained  so  that  they  are  reliable  and 
authentic.  In  addition,  they  should  be  legally  disposed  of 
only  under  an  authorized  disposition  plan.  Agencies  also 
need  to  ensure  that  records  remain  accessible  and  useable 
to  support  the  primary  purposes  for  which  they  were 
created  and  any  predicted  secondary  purposes  for  as 
long  as  the  records  must  be  legally  retained.  Records 
designated  as  ‘archival’  must  be  preserved  in  an 
accessible  and  useable  form  on  a  continuing  basis  by  the 
agency  or  transferred  to  the  relevant  archival  authority. 

A.  Maintain  integrity  of  records  as  created  {all 
related  data,  documents,  proofs  of  authenticity 
(e.g.,  electronic  signatures)  that  comprise  a  record 
of  a  business  transaction  can  be  accessed, 
displayed,  and  managed  as  a  unit}. 

B.  Accessible 

1 .  Records  or  part  of  record  can  be  easily 
retrieved  in  normal  course  of  all  business 
processes  in  a  timely  manner  throughout  the 
entire  retention  period. 

2.  Records  are  searchable  and  retrievable  for 
reference  and  secondary  uses  including  audits 
and  legal  proceedings  throughout  the  entire 
retention  period. 

a.  Complete  records  can  be  migrated  to  new 
system. 

b.  Related  meta  data  can  be  migrated  to  new 
system. 

c.  Functionality  necessary  for  predicted  use  of 
records  can  be  reproduced  in  new  system. 

[Note:  Functionality  should  be  based  on  predicted  use 
based  on  status  of  records.  For  inactive  records,  the 
ability  to  search  and  retrieve  records  may  be  sufficient. 
For  records  still  actively  engaged  in  a  business  process, 
full  functionality  may  be  necessary.] 
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3.  Copies  of  records  can  be  produced  and 
supplied  in  a  useable  format  for  business 
purposes  and  all  public  access  requirements. 

C.  Disposition 

1 .  Authorized  records  disposition  plan  can  be 
implemented. 

2 .  Authorized  individual  validates  or  changes 
records  destruction  or  transfer. 


3  .  System  Reliability 

System  should  be  administered  in  line  with  best  practices 
in  the  information  resource  management  (IRM)  field  to 
ensure  the  reliability  of  the  records  it  produces. 

Justification:  The  acceptance  of  records  for  legal,  audit, 
and  other  purposes  is  contingent  on  establishing  their 
authenticity  and  reliability  by  demonstrating  the 
trustworthiness  of  the  system  used  to  produce  them. 
Systems  that  produce  records  must  be  shown  to  do  so  in 
the  normal  course  of  business  and  in  an  accurate  and 
timely  manner.  System  administration  must  incorporate 
established  best  practices  in  the  data  processing  field. 
Policies,  procedures,  training  and  support  programs,  and 
controls  must  be  documented. 

A.  Recordkeeping  system  employed  exclusively  in 
normal  course  of  business. 

B.  Redundant  (paper)  recordkeeping  system  is 
discontinued. 

C .  System  management  roles  and  responsibilities  are 
assigned. 

1 .  Principle  of  separation  of  duties  is 
implemented. 

D.  Adequate  system  controls  are  in  place. 

1 .  Audit  trails  developed  and  implemented  within 
the  system. 

2.  Routine  tests  of  system  performance  are 
conducted. 

3 .  Reliability  of  hardware  and  software  is  tested. 

4.  Adequate  security  is  provided  to  prevent 
unauthorized  access,  changes,  and  premature 
destruction  of  records. 

5.  Controls  for  the  accuracy  and  timeliness  of 
input  and  output  are  established. 

6.  Problem  resolution  procedures  are  in  place. 

E.  Disaster  recovery  plan  is  in  place. 

F.  All  system  management  policies  and  procedures 
are  defined  and  documented. 

1 .  Changes  in  policy  and  procedure  are 
documented  and  implemented. 

F.  Training  and  user  support  are  adequate  to  ensure 
system  procedures  will  be  implemented  by  users. 
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The  Records  Requirements 
Analysis  and  Implementation 
Tool 


Records  Requirements  Analysis 
and  Implementation  Tool 

Records  Requirements 

Records  Requirements 

Elicitation  Component 

Implementation  Component 

Three  Levels  of 

Three  Types  of 

Requirements 

Implementation  Strategies 

-  Business  Process 

-  Management 

-  Record 

-  Policy 

-  System 

-  Technology 

The  Records  Requirements  Analysis  and 
Implementation  Tool  (RRAIT)  supports  the 
identification  of  records  management  requirements,  as 
well  as  strategies  for  their  implementation.  The  RRAIT 
is  composed  of  two  parts:  the  Records  Requirements 
Elicitation  Component  (RREC)  and  the  Records 
Requirements  Implementation  Component  (RRIC). 
Combined,  the  components  facilitate  the  identification  and 
implementation  of  application-specific  records 
management  requirements. 

The  Records  Requirements  Elicitation  Component 
(RREC)  facilitates  the  identification  of  records 
management  requirements  during  business  process 
improvement  and  systems  analysis  activities. 

The  RREC  itself  is  divided  into  three  levels: 

1.  Business  Process  Level  -  focuses  on  records 
management  requirements  associated  with  the 
business  process  that  is  to  be  automated. 

2.  Record  Level  -  captures  records  management 
requirements  associated  with  access  and  use  over 
time,  for  both  the  record  in  aggregate  and  its 
component  parts. 

3.  System  Level  -  focuses  on  how,  from  a  technical 
standpoint,  the  information  system  will  accommodate 
the  integration  of,  and  ongoing  access  to,  record 
components. 


The  Records  Requirements  Implementation 
Component  (RRIC)  supports  the  identification  of 
management,  policy,  and  technology  strategies  that 
address  the  requirements  once  they  have  been  identified 
by  the  Business  Process,  Record,  and  System  Levels  of 
the  RREC. 

The  figure  on  the  next  page  presents  the  conceptual 
overview  of  the  RRAIT  by  combining  the  components 
and  levels  into  an  integrated  picture  of  the  tool  and  its 
various  areas  of  emphasis. 


The  Records  Requirements 
Elicitation  Component 


The  RREC  translates  the  Functional  Requirements  into 
a  set  of  questions  or  prompts  that  assist  in  the 
comprehensive  identification  of  application-specific 
records  management  requirements.  The  goal  is  to 
seamlessly  integrate  the  capture  of  these  requirements 
into  activities  normally  conducted  during  business  process 
improvement  and  system  design.  The  three  components 
of  the  RREC  can  be  mapped  directly  to  the  three 
categories  of  Functional  Requirements  as  shown  in  the 
figure  above. 

The  following  sections  present  an  overview  of  each  of 
the  three  levels  of  the  RREC.  For  each  level,  we  provide 
a  description  of  objectives,  specify  questions  to  be 
addressed,  and  give  steps  and  hints  for  use. 
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RREC 


Records  Requirements  Elicitation  Component 
Business  Process  Level-  for  each  sub-task: 


Process  —►C  Decision^ 


Process 


Process 


1 .  Documents  or  Information  accessed 

2.  ‘How’  or  ‘when’  requirements  associated 
with  the  process 

3.  When  is  the  record  modified? 

4.  What  components  of  the  record  are 
created  or  modified? 

5.  Information  about  the  record  components 

6.  Proofs  of  authenticity  associated  with  the 
record  components 
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Record 


Records  Requirements  Elicitation  Component 
Record  Level 

1 .  What  is  a  ‘record’? 

2.  What  is  a  legal  minimum  record? 

3.  Required  record  structure 

4.  Information  about  the  record 

5.  Information  to  verify  authenticity  and 
interpretation 

6.  Internal  access  mechanisms 

7.  External  access  mechanisms 

8.  Reproducing  records  for  external 
dissemination 

9.  Records  disposition  plans 


Hardware, 

Software, 

and 

System 

Administration 


Records  Requirements  Elicitation  Component 
System  Level 

1 .  Integrating  records  from  other  systems 

2.  Systems  migration 

3.  Technology  standards: 

a.  Meta  data  requirements 

b.  Industry  standards 

c.  Jurisdictional  standards 


Technology, 
Management,  and 
Policy 
Strategies 


Records  Requirements  Implementation 
Component 

For  each  of  the  identified  RM  Requirements: 

Can  it  be  addressed  through  technology? 

If  yes... 

a.  Will  policies  need  to  be  developed  or 
changed? 

b.  What  sorts  of  management  practices  will 
be  required? 

If  no... 

c.  What  policies  and  management 
strategies  will  support  the  requirements? 


RRIC 
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RREC  -  Business  Process  Level 


Records  Requirements  Elicitation  Component 

Business  Process  Level 

1.  What  is  the  transaction  to  be  automated  (from  the  perspective  of  the  customer)? 

2.  What  are  the  subtasks  associated  with  the  transaction?* 

3.  For  each  of  the  subtasks... 

Basis  for  the  answer 

Legal 

Regulatory 

Best 

Practices 

Agency 
policies  & 
practices 

A.  What  is  the  purpose  of  the  sub¬ 
task?  Is  it  intended  to  fulfill  a  legal, 
regulatory,  or  operational  purpose? 

1 .  Are  there  any  "when'  or  liow’ 
requirements  for  the  transaction? 

(i.e.  time  clocks  or  standard 
professional  techniques) 

B.  What  other  documents  or 
information  must  be  accessed  during 
the  sub-task? 

C.  Is  the  record  of  the  transaction 
created  or  modified? 

1.  If  yes,  at  what  point  in  the 
transaction  is  the  record  created  or 
modified? 

2.  Who  is  authorized  to  change  or 
modify  the  record? 

3.  What  is  the  content  of  the  record 
or  the  component  of  the  record 
created  or  added  during  the  sub¬ 
task? 

a.  Are  there  documents  or 
information  created  by  other 
systems  that  must  be  integrated 
into  the  record? 

b.  Is  there  any  information  about 
the  component  of  the  record  that 
must  be  collected  and  maintained? 

c.  Are  there  any  proofs  of 
authenticity  associated  with  the 
content  created  or  modified  during 
the  sub-task? 

*A  sub-task  starts  a  process  and  ends  with  a  decision  point  or  completes  the  transaction. 

The  Business  Process  Level  of  the 
RREC  was  developed  to  support  the 
identification  of  records  management 
requirements  associated  with  a  given 
business  process.  It  is  also  designed 
to  identify  records  management 
requirements  that  are  required  by  law, 
regulation,  professional  requirements, 
or  organizational  policy  and  practices 
at  the  sub-task  level.  These 
distinctions  are  important  in  terms  of 
justifying  requirements  and 
determining  which,  if  any,  sub-tasks 
can  be  eliminated  or  modified. 


This  level  of  the  RREC  seeks 
information  at  the  record  component 
and  business  process  levels.  The 
records  management  requirements 
gathered  at  this  level  are  focused  on 
collecting  information  about  the 
process  itself,  and  the  modifications 
to  records  at  points  in  the  process,  in 
terms  of  how  the  record  is  modified 
(what  is  added,  deleted,  or  changed) 
and  the  individuals  who  have  authority 
to  make  the  modifications. 

The  Business  Process  Level 
questions  identify  required 
information  about  time  clocks 
associated  with  the  process  to  ensure 
that  information  about  start  and  end 
times  associated  with  a  given  task  are 
captured.  They  also  identify  other 
information  or  documents  that  may 
need  to  be  accessed  and  consulted, 
but  perhaps  not  integrated  into  the 
record,  so  that,  at  minimum,  the  system  will  allow  for 
references  to  these  sources.  This  section  of  the  RREC 
also  captures  information  about  the  types  of  documents 
that  must  be  integrated  into  the  record,  as  well  as  any 
proofs  of  authenticity,  such  as  original  signatures, 
notarizations,  or  electronic  time  stamps,  that  must  be 
captured  at  the  document  or  record  component  level. 


The  Business  Process  Level  of  the  RREC  also  supports 
the  identification  of  objects  (another  way  to  think  about 
components  of  a  record)  that  can  later  become  the  objects 
in  an  object-oriented  database  structure.  This  level  also 
identifies  the  required  meta  data  (information  about  the 
object  including  when  it  was  modified  and  by  whom)  for 
each  of  the  objects  or  components  of  a  record. 
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L  Gather  identity  records  nBaftagemettt 

issues.  Interviews,  surveys^  sad  focus  groiiqjs  sre  usefol  for 
this  step. 

2.  Create  a  process  atodel  or  dia^sra  that  tepreseots  the  entire 
busiaess  process  that  is  the  locus  of  the  analysis.  Hiiscaa  be 
done  in  a  groap  setting  or  erne  -or  a  fw  peopte  can  draff  the 
dmgratu  tbf  review  by  those  Who  pajtiolpafe  in  tho  business 

|i||||||||||||||||| 

3.  Conduct  a  workshop  or  group  decision  conteience  with  all 
statTmvoJved  in  the  process  to  accomplish  the  foiiowipgr 

3 .  L  Develop  consensus  and  common  dei mi  doas  around  the 
process  diagram  representing  the  current  business 
process. 

3  2.  Identity  snb-tasks  or  logical  breaks  to  the  proven. 

3.3.  For  each  of  the  Suh-tasks^  pose  the  questions  in  the 
Business  Process  Level  of  the  RREC  (careful 
transcription  and  org^ui^sation  of  rci^onsos  i$  critical). 

3.4.  Determine^  wherever  possible,  whether  the  records 
iRanagementrequiremenHs  based  on  alegal  or  regulatory 
requifBmentjj  proIessLonai  or  agency  best  practice^  or 


Identify  areas  where  there  exists  uncertainty  in  the 
responses  mii  Idendfy  mdivlduals  for  tbllow-wp. 

3.6.  Based  on  the  responses,  begin  to  identify  options  for 
improving  the  business  process.. 

4.  TransMc  the  requirements  into  system  specifications. 

L  Snb-tasks  that  result  in  no  change  in  the  record  are  likely 

to  addoo  value  to  the  process  nodmay  be  candidates  for 
modifteation,  elimination,  or  movement  to  another  patt 
of  die  process. 

2.  Minimizing  the  number  of  times  that  a  record  is  passed 
hack  and  forth  between  $taff  within  a  process  ean  reduce 
total  transacbon  time.  Attempt  to  identifyopportunities 
far  Gonsolidatlug  task  work  within  a  pass. 

3.  Records  management  requiremefits  that  are  not  based 
upon  Jegelor  regulatory  requirements  are  candidates  for 
modiflcutiou  or  ciimination.  For  each  of  the  identified 
reqairemeufe^  ask  the  questions:  **Why  is  it  done?"  and 
^*Does  it  need  to  he  done?” 


Steps  xnvop?ii>  in  wsbsg  the  Business  Frocess  Ievel  m  the  BBIC 

3.5, 
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RREC  -  Record  Level 


As  shown  in  the  figure  to  the  right, 
the  primary  unit  of  analysis  for  the 
Record  Level  of  the  RREC  is  the 
record  itself  In  general  terms,  this 
section  of  the  tool  seeks  to  capture 
records  management  requirements 
associated  with  access  and  use  over 
time,  for  both  the  record  in  aggregate 
and  its  component  parts.  The 
questions  are  focused  on  capturing 
records  management  requirements 
related  to  the  access  and 
maintenance  of  records  once  they 
have  been  created,  or  after  a 
business  transaction  has  been 
completed. 

This  section  of  the  RREC  identifies 
the  specific  components  of  the 
record  that  must  be  retrievable  and 
reproducible  for  use  by  both  internal 
and  external  secondary  users.  It  also 
focuses  on  the  identification  of  an 
organization’s  records  disposition 
plan,  including  the  individual(s) 
responsible  for  disposing  of  records 
according  to  the  plan  and  those 
responsible  for  modifying  or  updating 
the  plan. 

The  Record  Level  specifies  the 
information  that  must  be  collected  in 


Records  Requirements  Eliciation  Component  | 

_ Record  Level _ 

1 .  What  are  the  current  components  of  a  complete  or  final  record  of  the  transaction? _ 

2.  What  are  the  minima!  components  to  provide  evidence  of  the  transaction? 

(If  you  went  to  court,  what  would  be  the  minimum  information  that  you  would  need?) 

3.  Are  there  any  laws,  regs,  or  professional  best  practices  that  specify  the  structure 

(including  medium,  format,  reiationships)  of  the  record  or  any  of  its  components? _ 

4.  What  information  must  be  created  to  control,  manage,  and  access  the  record 

throughout  its  life-cycle?  (What  information  about  the  record  do  you  need:  e.g. 
who  created  it,  when,  etc.) _ 

5.  For  each  of  the  components  of  the  record,  what  information  Is  essential  to  access, 

verify  the  authenticity,  interpret  the  contents,  etc.? _ 

6.  During  what  other  business  processes  might  you  need  access  to  this  record? 

A.  For  each  of  these  other  business  processes,  which  components  of  the 
record  need  to  be  accessed? 

B.  For  each  of  these  business  processes,  what  are  the  best  ways  to 

access  the  records  (i.e.  indexing)?* _ 

7.  Who  are  the  externa!  secondary  users  of  the  record? 

A.  Which  components  of  the  record  are  required  by  external  secondary  users? 

B.  For  each  of  these  secondary  uses,  what  are  the  most  efficient/effective  ways  of 
accessing  components  of  the  records  (i.e.  indexing)? 

C.  How  will  the  record  be  reproduced  to  meet  the  needs  of  internal  and  external 
secondary  users? 

D.  What  are  the  rules,  laws,  and  regulationss  that  restrict  or  open  access  to 
these  records  to  external  users? 

E.  If  these  records  are  co\ared  by  FOIL: 

For  those  components  of  the  record  that  the  Agency  wishes  to  restrict 
access  to,  which  category  of  exemption  does  the  component  fall  under? 

For  each  of  the  components,  what  format  are  they  currently  in  (e.g. 

GIS,  database,  WP,  paper  forms,  narrative  maps)  and  how  will  they  be 
_ reproduced  for  distribution? _ 

8.  What  is  the  record  disposition  plan? _ _ 

9.  Who  is  responsible  for  authorizing  the  disposition  of  records? 

10.  Who  is  responsible  for  authorizing  the  development  or  changes  to  the 

records  disposition  plan? _ _ 

*  Identify  the  business  process  that  requires  the  most  robust  access  and  then  determine  if 
the  other  processes  require  additional  access  methods _ 


identifying  a  comprehensive  set  of  records  management 
requirements,  but  it  does  not  dictate  the  mechanisms  by 
which  the  questions  are  asked  and  answered.  Several 
methods  can  be  used.  For  example,  the  answers  can  be 
acquired  through  interviews  of  relevant  staff, 
conversations  with  experts  such  as  legal  staff,  group 
decision  conferences,  or  surveys.  The  method  used  to 
answer  the  questions  outlined  in  the  Record  Level  of  the 
RREC  should  be  determined  in  much  the  same  way  a 
research  method  would  be  selected  to  answer  a  research 
question.  A  variety  of  factors  need  to  be  considered  and 
the  most  cost-effective  mechanism  for  gathering  the 
information  should  be  used. 


iSrm  INVOLVED  m  VBmo  rm  Record  Level  of 

THE  RRBC 

L  Identity  all  the  mtemal  and  external  users  of  the  record 
g$;Remted  by  the  Ifitecessajy,  Identify 

a  aampte  of  ttsof s  to  address  the  raoord 

access  needs  questions. 

2.  Identiiy  and  gather  the  required  Information:  from 
indivldtiala  within  thoorpaiziation  who  m  familiar  with 
tho  lopl,  jofisdiotioimf,  and  proteional  host  pmcdcos 
associated  with  the  record  of  the  transaction. 

3.  Identify  and  gather  the  required  information  from 
mdivjdMb  mtemal  nr  external  to  ofgasfeation  who 
havorespoftaibility  Of  au&ority  over  the  maoegementaod 
disposition  of  records. 

4.  Trandate  the  requirements  into  system  specifications. 
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RREC  -  System  Level 


RecordsWequirements  Elicitation  Component 
System  Level 

How  will  the  system  accommodate  the  required  integration  of  records  from  other  systems? 

What  other  systems  might  these  records  be  migrated  to? _ 

What  is  your  system's  migration  plan? _ 

For  each  of  the  technologies  being  used  to  support  the  business  process: 

What  are  the  meta  data  requirements? 

What  are  the  industry  standards? 

_ What  are  the  jurisdictional  standards? _ 


The  System  Level  of  the  RREC  is  more  directly  related 
to  technology  than  the  other  levels.  As  shown  in  the 
figure  above,  the  questions  at  this  level  are  focused  on 
how  a  system  will  support  the  integration  of  the 
information  and  documents  (record  components)  identified 
at  the  Business  Process  and  Record  Levels.  In  other 
words,  the  Business  Process  Level  questions  facilitate 
the  identification  of  what  information  and  documents  must 
be  integrated  into  a  record,  the  Record  Level  focuses  on 
how  the  record  and  its  components  will  be  maintained 
and  accessed  over  time,  and  the  System  Level  focuses 
on  how,  from  a  technical  standpoint,  an  information 
system  will  accommodate  the  integration  of,  and  ongoing 
access  to,  record  components.  This  section  also  poses 
questions  about  future  system  migrations,  by  focusing  on 
the  types  of  hardware  and  software  platforms  that  the 
system  may  be  migrated  to  over  time.  These  questions 
prompt  the  user  to  consider  the  feasibility  of  alternative 
migration  plans  which  may  have  an  effect  on  current 
technology  choices. 

The  System  Level  questions  also  identify  meta  data, 
industry  standards,  and  jurisdictional  requirements 
associated  with  specific  technology  choices.  For  example, 
technologies  such  as  digital  imaging,  GIS,  and  EDI  may 
require  different  types  of  meta  data  and  may  require  that 
certain  standards  are  met  within  a  given  state  or  nation, 
or  these  standards  may  be  tied  to  commonly  accepted 
industry  standards.  Additionally,  industry,  organizational, 
or  professional  standards  for  system  administration,  back¬ 
up,  and  disaster  recovery  are  identified  through  this  level 
of  the  RREC. 


IWOLVEU  m  THE  OE  THE  SYSTEM 

Level  of  the  FtREC: 

l .  For  oach  of  tko  document  or  record  component  types, 
identify  how  the  system  wiU-'sapport  its  integration 
into  the  record.  In  tho$e  where  the  record 
coniponent  tmwt  he  ipcloded  lit  the  rcoord  directly; 
develop  an  indexing  and  storage  strategy  to  idendiy  the 
component  and  ife  loeation  outside  of  the  record 

Z  identify  other  ^ystotns  that  the  records  may  he  exported 

or  ttiij^^ted  to  over  time, 

3.  Develop  a  migradon  plan  that  me  fades  consideration  of 
each  of  the  identified  doemnent  or  record  component 
typc$- 

4.  In  conjuttctiott  with  the  tise  of  the  RfilC,  desedhed  below; 
identify  the  required  meta  data,  industry,  or  jurisdictional 
|s!ate,  local,  federal)  policies,  procedures,  and  standards 
that  must  he  accommodated  by  the  system. 

5.  Translate  these  re<jnircment$  into  system  spccificationa. 
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Records  Requirements 
Implementation  Component 

(RRIC) 


Records  Requirements  Implementation  Component  (RRIC) 


For  each  of  the  identified  records  management  requirements: _ 

Can  it  be  addressed  through  technology? _ 

If  yes, 

Will  policies  need  to  be  de\«loped  or  changed? 

_ What  sorts  of  management  practices  will  be  required? _ 

If  no, 

_ What  policies  and  management  strategies  will  support  the  requirements? 


The  Records  Requirements  Implementation  Component 
(RRIC)  focuses  on  the  identification  of  technology, 
management,  and  policy  strategies  to  address  the 
requirements  identified  through  the  Business  Process, 
Record,  and  System  Levels  of  the  RREC. 

The  RRIC  provides  an  organizing  framework  for  records 
management  requirements  and  strategies  for  addressing 
them.  In  some  cases,  the  same  technology,  management, 
or  policy  strategies  may  address  a  range  of  records 
management  requirements.  In  other  cases,  specific 
strategies  may  be  necessary  to  ensure  that  the  individual 
requirements  are  met.  For  example,  one  requirement 
might  state  that  the  record  of  a  completed  transaction 
should  be  moved  into  an  archival  vault,  at  which  point  no 
further  modifications  can  be  made  to  the  record.  This 
requirement  may  be  supported  by  technology  through  the 
use  of  workflow  features  that  move  the  record  into  another 
location  after  the  final  step  in  the  process  has  been 
completed.  However,  policies  must  be  created  that  clearly 
identify  the  components  of  a  ‘final  record’  and  when  in 
the  process  a  record  is  deemed  ‘final.’  Further, 
management  practices  must  be  put  in  place  to  govern 
who  is  authorized  to  move  the  record  into  the  vault  and 
what  components  of  the  record  must  be  maintained  in 
the  archive.  Once  the  management  and  policy  strategies 
have  been  determined,  technology  can  be  used  to  allow 
only  the  person  or  persons  authorized  to  archive  a  record 
the  technical  permission  or  capability  to  do  so.  Technology 
can  also  be  used  to  provide  an  audit  trail  to  ensure  that 
only  authorized  individuals,  at  the  appropriate  times,  have 
archived  the  record.  Another  policy  that  would  support 
this  requirement  would  be  a  prohibition  against  sharing 
user  IDs  and  passwords  among  the  system  users. 


While  there  is  no  pre-defined  method  for  using  the  RRIC, 
it  is  very  useful  to  implement  it  in  conjunction  with 
technology  awareness  activities.  We  recommend  an 
iterative  process  of  technology  awareness,  feasibility 
assessment,  and  technology  selection.  This  approach 
helps  the  organization  understand  the  full  range  of 
technology  options  and  their  costs  and  benefits  as  part  of 
the  determination  as  to  whether  records  management 
issues  should  be  addressed  by  management,  policy,  or 
technology  strategies.  Ideally,  an  organization  should 
strive  to  maximize  the  use  of  technology,  and  rely  less  on 
human  factors  to  ensure  that  records  management  issues 
are  addressed.  However,  this  may  not  always  be  cost- 
effective  or  feasible.  Therefore,  the  costs  and  benefits 
of  technology  strategies  compared  to  management  and 
policies  strategies  should  be  addressed  as  a  component 
of  the  RRIC. 


Implementation  Strategies  for  Records  Management  Requirements  H 

Strategies  | 

Policy 

Management 

Technology 

Requirement  1 

Requirement  2 

Requirement  3 

Requirement  ... 

Steps  involved  in  using  the  RRIC: 

.  L  Osthef  iftforjnatiott  about  poteutfeil  technology  choices  to 
support  the  business  process  and  associateii  records 
[  manajpmentrequireinents. 

2,  Gather  jatonnattou  on  such  costs  as  hardware,  software, 
Ualniiflg,  development,  system  integration,  development, 

‘  Assess  organizational  capabilities  or  organizational 

readiness  for  the  adoptjSon  of  aew  technology. 

4,  ■  Coudnet  an  analysis  of  the  cost  and  toasihillty  of  using 
initially  selected  technologies  to  address  the  records 
management  requirements. 

Test  the  technological  capabilities  and  reassess  feaslhlliy 
for  Implementation. 

6.  Identify  requiredccmpleinentarypolioy  and  management 
strategies  to  support  the  selected  technology  components . 

7.  Ideutiiy  indlvldoals  within  the  organization  to  assistln  the 
development  and  Implementation  of  required  management 
and  policy  strategies. 

Btnt:  The  ffaroework  above  is  a  useftjl  way  to  record  and 
compare  the  different  strategies  that  can  he  used  to 
implement  records  management  requirements. 
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General  Guidelines 


The  Functional  Requirements  present  records 
management  requirements  in  a  way  that  is 
understandable  to  both  program  managers  and 
technical  staff.  They  are  system-  and  business- 
process  focused,  which  means  that  both  practitioners 
and  system  developers  can  easily  relate  to  them.  The 
language  is  clear  and,  perhaps  more  important,  the 
requirements  constitute  a  concise  set  of  standards  that 
are  readily  adoptable  by  busy  managers  and 
professionals  across  organizational  types. 

The  RRAIT  focuses  on  the  business  process  and  business 
objectives.  Practitioners  indicated  that  this  manner  of 
presentation  enabled  them  to  understand  the  importance 
of  records  management  requirements  in  terras  of  the 
issues  that  are  critical  to  them  in  conducting  their  work. 
Records  management  professionals  stated  that  this 
approach  helps  ensure  effective  communication  with 
practitioners  about  records  management  issues. 

The  RRAIT  directly  translates  records  management 
requirements  into  user  and  system  requirements.  The 
responses  to  the  questions  in  the  Business  Process  and 
System  Levels  of  the  RREC  are  easily  communicated  to 
system  developers  in  terms  of  technical  specifications. 
Additionally,  the  questions  that  focus  on  the  documents 
or  components  that  constitute  a  record  and  on  internal 
and  external  access  to  records  can  be  readily  translated 
into  data  model  specifications.  The  tools  call  attention  to 
long-term  access  issues,  such  as  migration  strategies  and 
meta  data,  that  should  be  addressed  at  the  initial  system 
design  stage  to  avoid  high  costs  in  the  long  run,  or  worse, 
loss  of  access  to  important  records. 

The  RRIC,  with  its  focus  on  implementation,  highlights 
the  importance  of  developing  supporting  policy  and 
management  strategies  —  critical  elements  that  often 
receive  little  or  no  attention  in  system  development 
efforts. 

Together,  the  tools  provide  a  sound  framework  for 
identifying  and  addressing  electronic  records  management 
issues.  However,  as  is  the  case  with  any  tool  designed 
to  assist  organizations  in  addressing  key  issues,  success 
depends,  in  large  part,  on  the  environmental  context  within 
which  the  tools  are  applied.  Six  guidelines  for  use  of  the 
tools  are  provided  below. 


1.  An  organization  must  first  recognize  the 
importance  of  its  business  records  and  the  costs 
and  risks  associated  with  ignoring  them.  Without 
this  foundation,  it  is  unlikely  that  an  organization  will 
invest  the  time  and  attention  to  detail  that  the  tools 
demand. 

2.  The  degree  to  which  the  tools  are  effective 
depends  upon  the  organization’s  readiness  and 
willingness  to  change.  Change  means  more  than 
new  information  systems;  it  requires  supporting 
management  and  policy  strategies  as  well  as  an 
understanding  of  the  degree  to  which  records 
management  requirements  can  be  addressed  by 
selected  technologies.  In  short,  while  the  tools  support 
the  identification  of  requirements,  the  underlying 
factors  that  surround  their  implementation  determine 
the  ultimate  level  of  success. 

3.  One  of  the  most  critical  factors  for  effective  use 
of  the  tools  is  getting  the  appropriate  people  to 

answer  the  questions.  All  of  the  internal  and 
external  primary  and  secondary  users  of  the  records 
that  will  be  created  and  maintained  by  an  information 
system  should  be  represented.  While  only  a  sample 
of  each  user  type  may  be  involved  in  answering  the 
questions,  it  is  critically  important  that  all  of  the  types 
or  groups  of  users  be  consulted.  It  may  be  necessary 
to  bring  legal  staff  or  executive  management  into  the 
process.  Legal  staff  can  assist  in  the  identification 
of  statutory  or  regulatory  requirements,  while 
executive  level  staff  will  need  to  be  involved  in  the 
development  of  policy  and  management  strategies. 
Individuals  with  knowledge  of  the  professional 
practices  associated  with  a  given  process  are  also 
important  participants.  System  development  or 
technology  experts  also  play  an  important  role  in 
addressing  the  questions  and  providing  information 
about  product  capabilities  to  support  records 
management  requirements.  Not  all  of  the  players 
are  required  during  the  entire  process;  some  may  be 
brought  in  to  assist  as  different  questions  are  being 
addressed.  However,  identifying  and  involving  all 
key  players  at  the  appropriate  point  in  the  process  is 
critical  to  the  successful  use  of  the  tools. 
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4.  The  tools  help  organizations  identify  the 
functionality  that  is  required  in  a  system  to 
support  records  management  requirements. 
The  tools  emphasize  the  selection  of  technology 
solutions  that  maximize  inter-operability  and 
adherence  to  standards,  but  they  are  not  designed  to 
support  product  selection.  Selection  of  specific 
products  to  provide  the  necessary  functionality  must 
be  based  on  a  number  of  factors  including  existing 
infrastructure  (both  technical  and  organizational), 
cost,  and  expected  benefits. 

5.  Several  methods  can  be  used  to  answer  the 
questions  in  the  RRAIT.  We  strongly  recommend 
that  the  Business  Process  Level  questions  be 
answered  in  the  context  of  a  business  process  analysis 
or  improvement  activity.  The  methods  for  answering 
questions  in  other  sections  should  be  selected  based 
on  their  compatibility  with  the  organization’s  skills 
and  time  schedules,  and  the  method’s  ability  to 
minimize  the  total  cost  of  the  information  collection 
process. 


6.  Technology  awareness  activities  should  he 
conducted  in  conjunction  with  the  use  of  the 
tools.  Product  reviews,  vendor  presentations,  and 
conferences  focused  on  technology  applications  are 
all  ways  to  increase  user  awareness  of  technology 
capabilities  and  limitations.  These  types  of  activities 
increase  understanding  of  the  strengths  and 
weaknesses  of  technology  types  and  specific 
products.  A  broad  appreciation  of  what  technology 
can  and  cannot  do  will  help  the  organization  make 
appropriate  technology  choices. 


This  document  is  available  on-line  at: 

http://www.ctg.albany.edu/resources/pdfrpwp/mfa_toolkit.pdf 

The  complete  project  report,  Models  for  Action:  Practical  Approaches  to  Electronic  Records  Management 
and  Preservation,  CTG  Project  Report  98-1,  is  available  at: 

http://www.ctg.albany.edu/resources/pdfrpwp/mfa.pdf 


Practical  Tools 
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